This Page is Inserted by IFW Miexinf mi ScaMlffif 
Operations and Is not part of the Official Record 

BEST AVAILABLE IMAGIS 

Defective images within this document ^e acciarate mpcos^^^m iie ori^ 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 

□ black BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 

□ FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES- ^ 

□ COLOR OR BLACK AND WHTTE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 

□ LINES OR MARKS ON ORIGINAL DOCUMIMT 

□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED AME POOR QUALITY 

□ OTHER: - ■ - - — 

IMAGES AME BEST AVAILABLE COPYo 
As rescamittg these doeumeiits will mot correct tto® im^ge 
problems checked, please do not report these preWem^ to 
the IFW Image Problem Msiilliox. 



Page Blank (uspto) 



PCX 



WORLD INTELLECTUAL PROPERTY ORGANIZATION 
Imcmauonal Bureau 




INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATS (PCT) 



(51) International Patent Classification 6 
G06F 9/40 



Al 



(11) International Publication Number: 
(43) International Publication I>atc: 



WO 98/04971 

5 Febnjarv 1998 (05.02.98) 



(21) International Application Number: PCr/US97/122I4 

(22) International Filing Date: 25 July 1997 (25.07.97) 



(30) Priority Data: 

08/686.312 



25 July 1996 (25.07,96) 



US 



(71) Applicant: TRADE WAVE CORPORATION [US/US]; Suite 

100. 3636 Executive Center Drive, Austin, TX 78731 (US). 

(72) Inventors: PAINTER. Paul. B.; 8812 Grape Cove. Austin, TX 

78717 (US). HARDIN. John, W,; 8702 Pepper Rock Drive, 
Austin, TX 78717 (US). 

(74) Agents: SHOWALTER, Donald, S. ct al.; Holland & Knight 
LLP. One East Broward Boulcvarxj (33301). P.O. Box 
14070, Fort Laudertiale, FL 33302-4070 (US). 



(81) Designated States: AL, AM. AT, AU, AZ. BA. BB. BG. BR 
BY, CA, CH. CN. CU. CZ, DE, DK. EE. ES. FI. GB. GE. 
HU, IL. IS, JP. KE, KG, KP. KR, KZ, LC. LK. LR, LS. LT 
LU. LV. MD, MG. MK, MN. MW, MX, NO, NZ, PL. PT. 
RO, RU, SD, SE, SO. SI, SK. TJ. TM. TR, TT, UA. UG 
UZ. VN, ARIPO patent (GH. KE, LS, MW. SD, SZ. UG. 
ZW). Eurasian patent (AM, AZ, BY. KG. KZ. MD. RU, TJ, 
TM). European patent (AT, BE, CH. DE, DK. ES FI FR 
GB, GR, IE, IT, LU, MC, NL. PT. SE), OAPI patent (BF* 
BJ. CF. CG, CI. CM. GA, GN. ML, MR, NE. SN, TD, TG) 



Published 

With international search report. 

Before the expiration of the time limit for amending the 
claims and to be republished in the event of the receipt of 
amendments. 



(54) Title: METHOD AND SYSTEM FOR GENERALIZED PROTOCOL IMPLEMENTATION ON CLIENT/SERVER COMMUNICA- 
TIONS CONNECTIONS 




Connection 
Manager 

(CM) 



(57) Abstract 

A client (3) and server (5) interposed by a connection manager (6) for implementing communications protocols between a client (3) 
and server (5) in a transparent, applicaiion-independem, non-invasive fashion. The connection manager (6) comprises a client component (3) 
typically resident on the client machine (2) and a server component (5) typically resident on the server machine (4). The client component 
(3) accepts connection requests from client applications and sets up those connections in cooperation with the server component (5) of the 
connection manager. The conixection manager (6) identifies the type of connection requested (e.g.. ftp, http. gss-http) based on such things 
as the content of the request and invokes methods specific to the type of connection requested. In this manner, the connection manager 
carries out the higher-level protocols, such as security protocols, for the connection in a vvay that is transparent to both the client (3) and 
server (5). 



<WO 9804971 A1> 



FOR THE PURPOSES OF INFORMATION ONLY 
Codes used ,0 identify Su.e, pany ,o the PCT on ,he front page, of pamphlets publishing intentional applications under the PCT. 



AL AlbwiU 

AM Annenia 

AT Auslrit 

AU AiuiriHa 

AZ Azerbiijui 

BA Botnta and Henecovina 

BB Barbadm 

BE Belgium 

BF Burtctna Faso 

BC Bulgaria 

BJ Benin 

BR Brazil 

BY Belarus 

CA Canada 

CF Ccniral African Republic 

CO Congo 

CH Swicnerland 

Cr CUc d'lvoire 

CM CamenxNi 

CN China 

CU Cuba 

CZ Cttch Republic 

DK Gcnmany 

DK Denmark 

KE Hstonia 



ES 
FI 
FR 

GA 
GB 
GE 
GH 
GN 
GR 

m 

IB 
IL 
IS 
IT 
JP 
KB 
KG 
KP 

KR 

KZ 

LC 

LI 

LK 

LR 



Spain 
Finland 
Frattce 
Gabon 

United Kingdom 

Georgia 

Ghana 

Guinea 

Greece 

Hungary 

IrelMid 

Iirael 

Iceland 

Italy 
Japan 

Kenya 

Kyigyzitan 

Democratic People *t 

Republic of Koi«a 

Republic of Korea 

Kuakuan 

Saini Lucia 

Liechienstein 

Sri Lanka 

Liberti 



LS Lesotho 

LT Lithuania 

LI) Luxembourg 

LV Latvia 

MC Monaco 

MD Republic of Moldova 

MG Madagascar 

MK The former Yugoslav 
Republic of M«:edonia 

ML Mali 

MN Mongolia 

MR Mauritania 

MW Malawi 

MX Mexico 

NE Niger 

NL Netheriandi 

NO Norway 

NZ New Zealand 

PL Poland 

PT Poaugal 

RO Romania 

RU Rusiian Federation 

SD Sudan 

SE Sweden 

SG Singapore 



SI 


Slovenia 


SK 


Slovakia 


SN 


Senegal 


sz 


Swaziland 


TD 


Chad 


TG 


Togo 


TJ 


Tajikistan 


TM 


Tyirkmenistan 


TR 


Turkey 


TT 


Trinidad and Tobago 


UA 


Ukraine 


UC 


Uganda 


US 


United States of Aincrira 


uz 


Uzbekistan 


VN 


Viet Nam 


YU 


Yugoalavta 


zw 


Zimbabwe 



JNSDOC) D: <WO 980497 1 A 1 > 



INTERNATIONAL SEARCH REPORT 



Intcmaiionai applicAiion No 
PCT/US97/122I4 



A. CLASSIFICATION OF SUBJECT MATTER 
IPC(6) :G06F 9/40 
USCL :395/680 

According to Intcmahonal Patent CUssification ( IPC) or to both national claisificabon and IPC 

R FIELDS SEARCHED . 

Minimum documentation searched (classification system foi lowed by classification symboJs) 
U.S. : 39S/680; 683. 1S7.0I. 186. 188.01. 200.1 

Documentation searched other than minimum documentation to the extent that such documents are included in Che Helds searched 



Electronic dau base consulted dunng the international search (name of dau base and. where practicable, search terms used) 
APS 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category* 


Citation ol document with mdication, where appropnate. of the relevant passages 


Relevant to clatm No 


Y 
Y 


us 5,506.961 A (CARLSON etal) 09 APRIL 1996, col. 7, line 12, 
col. 8, fig. 3. 

US 5,509,121 A (NAKATA etal) 16 APRIL 1996, col. 1, lines 30- 
35, col. 2, lines 38-40, col. 3, lines 55-63. 


1-2 
1-2 


{ { Further documcnU are listed in the continuation of Box C. [ | See patent family annex. 


* special eaUgoriM of ciim6 docu»«nu *T* Uur doe\ani«nt publith«d nfxmr thm mumational Hling d»u or priority 
^ . , dita «nd not in conflict wich th« «ppJic*uon but ciud to urwleniAnd 
•A' docun*ftt d*riniflg th* s«n«ral itato of Uw art which » not ooiUMftartd pnnciple or ih«ory urwkriyini tha tnvaoOon 
to ba of partieular ratavanca : . r- r j -9 

•E* «arl>«r do«ii»am publnhad on oi aflar Iba iniani«tional r.lin« dau documam of paiiicular rtljv«i«; th. cl.«n.d mvnoon c«vK,t b« 

^ conttdarao noval or canno* b« coniMUfad to mvol«« an mventiva ftep 
•L* <k>cum«m which may throw doubu on pnonty elaimi*) or which u »*»• doeuioani u t«kan aJona 
ciicd to atlabltah tht pubtteatioo dau of another ciUtKMi or other 

ipacial raaaon ia» tpaciftcd) docuinant of pafliCuUr ralavancc; the claimed tnvenuon cannot be 

coniidarad to tnvolva mn mvanbva ii«p whan the documani ii 
*0' documani rafaiTing to an oral diacloaufa. um. whibtlMm or othar aombtnad wtih on* or mora o«har auch docuniAnu, luch cofnbuiat*on 
maana bamg obvioua to ■ paraon tkillad m tha an 

•P- docuinant pufoluhad prior to tha inwnwuonal nimg dau but Utar than .4. doeumant m«nbcr of th« una patent family 
tha pnonty data elaimed 


Date of the actual completion of the international search 
08 OCTOBER 1997 


Date of mailing of the international search repon 

JL2 0EC1997 


Name and mailing address of the ISA/US 
Commtuioner of Pitenu and Trademarks 
BoxPCT 

Wathtnston. D C 20231 
Facsimile No. (703) 305-3230 


Authomwrforfici^ 

%VIN KREISS 
Telephone No. f703) 305-9600 



Form PCT/lSA/210 (second sheetXJuly 1992)* 



BNSDOCID: <WO 9B04971A1> 



wo 98/04971 PCT/liS97/I2214 



14/14 FROM FIG. 5E ( 



E. CM/S: Write Client Request to Server 
IV. Client: Read Response from Server (CM/C) 

A. CM/S: Read Server Response 

1. CM/S: Read Server Response Line 
HTTP/1.0 200 OK[CR/LF] 

2. CM/S: Read Server Headers and Body 
Content-fype: text/plainfCR/LFl 
[CR/LF] 

Hello, John Smith! 

B. CM/S: Write Server Response to Client 

C. CM/S: Close Server Connection 

D. CM/C: Read Server Response 

1. CM/C: Read Server Response Line 

2. CM/C: Read Server Headers and Data 

E. CM/C: Write Server Response to Client 

F. CM/C: Close Server Connection 

V. Client: Read and Display Server Response 

VI. Client: Close Connection to Server (CM/C) 



FIG. 5F 
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FtELD OF THE INVENTION 

The present invention relates to computer networks having enhanced and/or 
extended client/server communications. More particularly, the present invention is 
characterized by an application-independent, object-oriented connection manager for 
5 processing client/server connections (communications sessions) between client 
computers and server computers. 

BACKGROUND OF THE INVENTION 

Client/server communications between client computers and server computers 
0 are commonly established by the interaction of an application program running on the 
client and a corresponding application program running on the server. The client/server 
model is the conventional model governing the transfer of data between application 
programs on a computer network. According to this model, the high-level protocols for 
reading and writing data between a first computer (the client) and a second computer 
5 (the server) are embedded in the application software running on the client and sen/er. 
respectively. Prior to the transfer of data, a communications session must be 
established over the network between the client and the server. 

Such a communication session is established according to a number of "layers " 
of protocols. Among the lowest level protocols, physical connectivity between the client 
) machine and the server machine is established and maintained. For example, the 
Ethernet CSMA/CD protocol is a common data link layer protocol governing the orderly 
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transmission of packets of data between a client and server. Higher-level protocols, 
such as the TCP/IP and XNS transport layer protocols, govern the assembly of data 
into messages and the uniform addressing of various computers on the network Due 
to the established nature of protocols at these levels, much client software has these 
5 protocols "built-in" so that these protocols are automatically employed when the client 
software is run on a client or server machine on the network. 

Still higher level protocols govern the interoperability of particular client/server 
applications such as file transfer, remote file access, electronic mail. etc. Examples of 
such applications include Internet-based applications, where use of a file transfer 
10 protocol pennits the transfer of files from ftp server sites (ftp://xxx.xxx); a different 
protocol permits a client to browse documents in hypertext mark-up language (html) 
format at http server sites (http://xxx.xxx); and yet another protocol governs the 
establishment and maintenance of secure communications sessions between a client 
and server at gss-http sites (http://xxx.xxx:488). For these higher-level protocols, each 
15 client/server application is typically specially adapted at the source code level to 
implement these protocols. In other words, the task of setting up a client/server 
communications session employing the desired protocol is typically accomplished by 
application-specific code developed by the application vendor for permitting the 
application program to be run on a client and communicate with a server on the network 
20 using higher-level protocols such as ftp. http. or gss-http. 

3 
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Protocols for establishing secure client/server connections have conventionally 
been handled in the foregoing manner. For example, Intemet Web-based client 
applications often employ software security packages to establish secure client/server 
communications, but only after the application software has been invasively modified at 
the source code level to interoperate with the security program. Thus, the application 
program at the server must 'know" that a security protocol is being employed, and the 
application program must be specially adapted to work with the security protocol. 

The need for transparent and application-independent client/sen/er 
communications management for implementing a variety of higher-level 
communications protocols has been recognized. For example. Gradients 
WebCrusader software allows users to securely access distributed applications using 
standard, off-the-shelf Web browsers installed on desktop client systems. This product 
is purported to establish a secure session between an off-the-shelf Web client 
application and a Web server using the DCE (Distributed Computing Environment) RPC 
15 (Remote Procedure Calls) protocol. WebCrusader comprises an application- 
independent "Connect Client" function resident on the client machine which interacts 
with the client application, usually a Web browser. The Connect Client, in conjunction 
with a corresponding "Connect Server" function resident on the sen/er. uses the DCE 
RPCs to fonvard requests from the Web browser to the server. The Connect Server 
20 function receives these requests, performs security checks, fetches the requested 
document, and uses DCE RPCs to send the document securely back to the Connect 
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Client for forwarding on to the Web browser. The Connect Client acts as a "proxy." 
intercepting document requests from the Web browser and determining whether a 
secure document is sought. If the URL of the requested document contains a DCE 
name, the Connect Client uses DCE RPCs to fon^^ard the request to the Connect 
5 Server resident on the secure server. If the URL contains a non-secure address, the 
Connect Client forwards the request to the appropriate standard Web server using http 
In this way, the WebCrusader transparently performs the security functions of 
authentication, authorization and encryption between a client application and a server 
using DCE. The software is strictly limited to the RPC protocol between client and 
10 sen/er, however, and is not stream-based. 

What is needed is an application-independent client/server connection manager 
suitable for use with any higher-level protocol, such as ftp, http. DCE and gss-http 
without having to convert to RPC call sequences. It is desired that such a connection 
manager tansparently set up and manage both secure and non-secure client/server 
15 byte-stream sessions, yet inter-operate with each application only at the object code 



level. 



SUMMARY OF THE fNVENTlON 

According to a first aspect of the invention, there is provided a client machine 
20 and a server machine in a computer system, wherein the client and server include a 
connection manager for establishing communications sessions using higher-level 
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protocols such as http. ftp. or gss-http. The client machine may be any computer 
capable of running a client application, and will typically include a memory device such 
as a hard disk drive for storing the client application; a processor for executing the client 
application; and means for handling input/output (I/O). 

The connection manager typically comprises a client component running on the 
client machine, and a server component running on the server machine. These dual 
components of the connection manager together manage a series of connections 
between a client application and a server application. The client component receives 
requests from the client application and uses the request to set up and manage a 
communications session with the sen/er application wherein responses from the server 
are received by the server component of the connection manager. The client aspect 
and the sen/er aspect are thus in part mirror images of each other, and they function 
jointly as an "agent " of the communications between the client and the server. 

It will be understood that the connection manager, including its client and server 
components, can be run on a machine other than the client machine (on which the 
client application mns) or the server machine (on which the server application runs). 
For example, in a networked office environment, a client machine mnning a client 
application may be interoperable with a separate machine running the connection 
manager, which may then apply the appropriate protocols and enhancements to the 
connection between the client application and a distant server application. 
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The connection manager handles requests from a cHent application using an 
object-oriented approach to process (set up and manage) the communications session 
between the client application and the server application. The connection manager is 
"object-oriented" in that it uses various discriminators determinable from the client or 
5 server communication content (e.g.. protocol, client or sen/er address, data type, etc.) 
to evaluate which type of communications connection, or class, is called for By 
obsen/ing these discriminators, the connection manager can "type" the object and call 
on the communications methods corresponding to that class of connection when setting 
up the communications session and carrying out the communications protocols 
10 between the client and the server. 

According to a second aspect of the invention, the connection manager Is 
application-independent. A variety of client/sen/er applications may be used with the 
connection manager, and these applications need not be adapted for use with the 
connection manager. The connection manager receives ordinary requests originated 
15 by either the client or the server and uses the content of those requests to set up and 
manage a communications session between the client and the server. Requests from a 
wide variety of applications and for a wide variety of classes of connections can be 
accommodated by the connection manager in this manner. 

According to a third aspect of the invention, the connection manager maintains 
20 one or more active "listener" objects that await requests for connections of particular 
types. When a connection is accepted on a particular listener, the connection manager 

7 
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associates with that connection the group of communications methods for connections 
of that class. 

According to a fourth aspect of the invention, there is provided a client/server 
connection manager which is non-invasive with respect to the various applications with 
5 which it may operate. The connection manager receives high-level, connection-specific 
requests from the client. The connection manager uses these requests to determine 
the lower-level protocols required for creating the desired type of connection, such as a 
secure communications session. The connection manager employs client-resident 
portions and server-resident portions to manage the communications and supply the 
10 lower-level protocols without any modifications to the client application or the server 
application at the source code level. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1A is a simple block diagram representation of a client/server connection 
IS manager according to the present invention. 

FIG. IB is a block diagram of a client/server connection manager separated into 
its client and server components in a distributed computing environment. 

FIG. 2A is a functional design diagram of the client component of a connection 
manager with active listener objects which determine when connections of various 
20 types are requested by a client application. 

8 
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FIG. 2B is a functional design diagram showing a single listener object 
associated with a single class of methods for an http connection. 

FIG. 3A is a flow chart of the functioning of a client/server connection manager in 
the computer system according to the present invention. 

FIG. 3B is a more detailed textual outline of the flow chart shown in FIG. 3A 

FIG. 4A is a communications activity flow diagram showing the establishment of 
a communications session between a client and a server using only the client 
component of a connection manager. 

FIG. 4B is a textual outline of the communications activity shown in FiG. 4A. 

FIG. 5A is a communications activity flow diagram showing the establishment of 
a secure communications session between a client and a server using both the client 
component and a server component of a connection manager. 

FIG. 58 is a textual outline of the secure communications activity shown in FIG 

5A. 



DETAILED DESCRIPTION O F THE PREFgRRED EMBODIMENT 

Referring now to the Figures, the invention in its simplest form is illustrated in 
FIG. 1A. wherein a client machine 2 and a sen/er machine 4 are interposed by 
connection manager 6. Client machine 2 may have resident thereon one or more client 
20 applications 3. and these applications will typically interact with one or more sen/er 
applications 5 to obtain data, files, graphics, etc. from the various servers. For 
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example, server machine 4 may be a server for one or more of ftp. http. or gopher 
programs on the Internet, or it may be an electronic mail server or other sen/er on a 
private network. The invention encompasses any type of client/server combination 
where such is interposed by a connection manager of the type descnbed. 
5 Connection manager 6 in its simplest form resides on client machine 2 and 

manages the connections between the various client applications 3 and their target 
server applications 5. Connection manager 6 sets up and manages these client/server 
connections using an object-oriented approach to determine, based on the type of 
connection sought by the client application 3 or the sen/er application 5. the appropriate 

10 class of communications methods to apply to the connection so that input/output (I/O) 
between the client and sen/er is processed seamlessly and transparently. The object- 
oriented approach of connection manager 6 is described more fully below with 
reference to FIGS. 2A and 2B. 

Referring to FIG. IB. connection manager 6 is shown to comprise client and 

15 sen/er components where the client machine 2 and sen/er machine 4 communicate at 
the application level over a network 8. Those components are designated connection 
manager/client (CM/C) 10 and connection manager/server (CM/S) 12, respectively. 
CM/C 10 typically receives from the various client applications 3 certain connection 
requests destined for sen/er applications 5. CM/C 10 types the object, or connection 

20 sought, according to the content of the request from client application 3. CM/C 10 and 
CM/S 12 then cooperate to establish the requested type of connection, applying the 

10 
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appropriate higher level protocols through the collection of methods specific to the 
requested type of connection. For example, if client application 3 requests a secure 
(gss-http) Web connection. CM/C 10 and CM/S 12 invoke the communications methods 
associated with the gss-http class of connection; neither the client application 3 nor the 
5 server application 5 may be aware that the gss-http protocols are being implemented by 
CM/C 10 and CM/S 12. 

Once a connection is established by the components of connection manager 6, 
I/O between client application 3 and server machine 4 is dispatched by CM/C 10 and 
CM/S 12 in a way that is transparent to the client and server. CM/C 10 invokes the 

10 communications methods associated with the particular type of connection established 
(e.g., Init, connect, read and write methods for an http-class connection), thereby to 
carry out the necessary protocol and giving the appearance that client application 3 is 
receiving I/O from the server application unaided by any other application or utility 
Thus, it can be seen that CM/C 10 interacts with client application 3 as if CM/C 10 were 

15 in fact a server application. Likewise, server application 5 interacts with CM/S 12 in the 
same way that sen/er application 5 would ordinarily interact with a client application. 
The connection is thus transparent to client application 3 and server application 5, 
which require no special knowledge that the components of connection manager 6 are 
interposed between the client and the server. 

20 Referring now to FIG. 2A. the establishment of client/sen/er connections by 

CM/C 10 is described. FIG. 2A representationally shows a plurality of logical 

11 
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connections established between various client applications 3' and 3" and their target 
sen/er applications via a computer network. CM/C 10 is preferably provided with an 
intializer 30 for setting up a plurality of listener objects 16. Listener objects 16 are 
tailored, through their association with connection classes 31. to detect a request for a 
5 particular type of connection from client applications 3' and 3", wherein each 
connection class 31 defines a collection of communications methods that implement 
protocols specific to a connection type. When CM/C 10 accepts a connection from a 
client application 3* or 3". CM/C 10 associates with that connection the communications 
methods corresponding to that type of connection. 
10 When CM/C 10 accepts a connection request from client application 3' or 3", 

CM/C 10 creates a connection object 24 for http connection 18. a connection object 26 
for http connection 20. or connection object 28 for gss-http connection 22. Connection 
objects 24. 26 and 28 are specialized by their respective connection classes 31 to 
handle connections of particular types. The connection objects have pointers to the 
15 actual client and sen/er connections, pointers to specific methods of connection classes 
31. and other Information allowing them to be managed by CM/C 10. For example, the 
http connection class's Init method (http_lnit) sets connection object 24's read, write, 
exception, and deinit methods to http_Read. http_Write. http_Exception. and 
http_Deinit. respectively. Event manager 14 calls the connection class methods for 
20 each connection object in order to process I/O events and apply enhancements to the 
protocols for each connection, e.g., adding security to http. 



12 



BNSDOCID:<WO 9804971A1> 



wo 98/04971 



PCT/US97/12214 



CM/S 12 is preferably designed to mirror the operation of CM/C 10 and may be 
designed similarly to accept communications requests on behalf of server application 5 
and receive communications from the sen/er. For simple connections such as http 
connection 18. where data is written to and from CM/C 10 without the need for 
5 enhanced protocols such as security protocols, CM/S 12 may not be active on the 
sen/er side, and connection manager 6 may then be considered to comprise only CM/C 
10, which connects directly to server application 5. 

FIG. 2A shows the establishment of three different types of connections by CM/C 
10, although any type of connection can be accommodated by the present invention. 
10 There is shown representationally a logical, non-secure http connection 18 between a 
client application 3' and a server application 5 (not shown). This connection typifies the 
non-secure Internet communications between a client and server. Also shown are http 
connection 20 and secure gss-http connection 22. which employs the gss-http protocol. 
CM/C 10 cooperates with CM/S 12 (not shown) to set up each connection on 
15 appropriate ports of sen/er machine 4. For example, http connection 18 and http 
connection 20 are typically set up on non-secure ports 80, while secure gss-http 
connection 22 is set up on secure server port 488 according to current standards. 

After the connections are established by CM/C 10 and CM/S 12. I/O between 
client application 3 and sen/er application 5 is processed according to a collection of 
20 methods which are specific to the type of connection established. In FIG. 2A are shown 
connection objects 24, 26. and 28 which are associated with the methods for the http 
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class, http class, and gss-http class of connection, respectively Typical methods 
include read, write, init and connect, although numerous methods may be invoked 
depending on the connection type and the methods which are suitable for the particular 
connection type. The functioning of current methods is well known. For example, the 
http read method is invoked any time input data from either the client application 3 or 
the server application 5 is available on an associated connection. The http init method 
is invoked as soon as a client connection is accepted by CM/C 10. And the http 
connect method is invoked as soon as a server connection is established by either 
CM/C lOorCM/S 12. 

The methods of FIG. 2A may be implemented in any of a variety of ways, 
including subroutines (both statically and dynamically linked), executing local 
applications, remote procedure calls. Active-X and Java Statically and dynamically 
linked subroutines have proven to be an acceptable means for implementing these 
methods. 

Referring now to FIG. 2B. there is shown a functional design diagram of CM/C 
10 for a single http-class connection. Connection class 31' defines the class of http 
methods specific to the http connection class. Listener object 16* receives a connection 
request on http connection 18. In response. CM/C 10 accepts the connection request 
and creates connection object 24, which has pointers to the http read method 60". write 
method 66'. connect method 64' and exception method 65. CM/C 10 also associates 
connection object 24 with the http methods of connection class 31". Event manager 14 
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makes calls to these methods to process the I/O on http connection 18. I/O events 
(e.g.. reads, writes, and exceptions) may originate from either the client or the server. 
Processing of these read and write events is handled by event manager 14 via process 
read routine 48 and process write routine 50. which make the appropriate calls to the 
5 methods associated with the connection object. 

Referring now to FIG. 3A. there is shown a flow chart of the functioning of 
connection manager 6. which preferably has basic functions provided by an initialization 
routine 30, an event processing routine 32, and a quit routine 34. Initialization routine 
30 is executed once upon startup, and includes steps preliminary to establishing 

10 client/server connections. In step 36. initializations specific to the platform on which 
connection manager 6 is installed are carried out. The various program rhodules of 
connection manager 6 are initialized in step 38. The connection class definitions 
(reference numeral 31 in FIG. 2A) for connections to be managed by connection 
manager 6 are loaded in step 40. The appropriate methods for use with each 

15 connection class are initialized in step 42 and the listener objects 16 (FIG. 2A) are 
created in this step. 

Event processing routine 32 processes I/O events, and these are preferably 
processed according to a process read step 48. a process write step 50. and a process 
exception step 52 for handling error conditions on the connection. In step 54. a read 
20 request is examined to determine whether it originated from the client or the server. If 
the read request originated from the client, step 56 determines whether it is a request to 
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read data from the client or instead a request to accept a connection from the client. 
Requests to accept a connection invoke Init method 58 to specialize the connection 
object 24 created by connection manager 6. In contrast, requests to read data invoke 
read method 60. Read requests originating from the sender likewise invoke read 
5 nnethod 60. which occurs when data is to be read from the server and written to the 
client. 

Write requests are handled by process write step 50. which first determines (step 
60) whether the request is destined for the client or the server. If the write request is 
destined for the server, step 63 determines whether it Is a request to write data to the 
server or instead a signal that a server connection request previously issued has 
completed. Requests to write data invoke write method 66. Write requests destined for 
the client likewise invoke write method 66, which occurs when data is to be written to 
the client. 

Event processing routine 32 may handle events other than I/O events. These 
15 include user events, such as an indication from the user that he wants connection 
manager 6 to exit. They may also include programmatic events (e.g., another program 
wants connection manager 6 to exit), and so on. 

In the typical http connection, the read, write. Init and connect methods are 
sufficient to establish the communications session and handle all I/O between a client 
20 application 3 and a server machine 4. If communication is over a networic, components 
CM/C 10 and CM/S 12 typically mn respectively on client machine 2 and server 
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machine 4. with each component handling both read and write requests from the client 
and the server according to the steps above. 

When all connections are to be tenninated. quit routine 34 carries out step 68 to 
delete any active connection objects (which closes all open connections) and step 70 to 
deinitialize the classes of connections previously initialized in step 40. FIG. 3B shows 
in outline form the various steps of FIG. 3A. 

Example A: Unsecure Web Connection rhtt p ) 
Refen-ing to FIG. 4A, there is shown an activity flow diagram for a simple, non- 
secure client/sen/er connection which is set up and managed by connection manager 6. 
In the example, an http class connection is established on the Internet; client 
application 3 is therefore presumed to be a Web browser and server machine 4 is 
presumed to be a Web server. Because no higher-level network protocols (such as 
security protocols) are required, connection manager 6 resides only on the client 
machine 2. Prior to the initiation of the activities shown in FIG. 4A. it is presumed that 
connection manager 6 has been initialized and that at least one listener object 16 (FIG. 
2) of the http class is active. 

The operation of connection manager 6 for http-dass connections is now 
described. Typically, a user of client application 3 (Web browser) enters the Universal 
Resource Locator (URL), such as: 

http://server.com 

which identifies a Web site to be browsed (step 101). In response to the user entry of a 
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URL. c,«n, app.icaUo„ 3 in .,ep 102 anempts ,o open a oonnectlon ,o CM/C ,0 which 
olien, application 3 treats as a se.er appi^tion S. Connec«on manager 6. which has 
leas, one ac.h« h«p listener object 16- ,F,G. 2A,, accepts me connection and 
invokes the ,ni. ™thod assocated w«h the accepUng connection object ,in ,h,s case 
http.M). A. this point and throughout the exampte, client application , Interacts w«h 
oonnectlon manager 6 as if it were the server: thus client application 3 now treats the 
connection as having been established »m server application 5 In step 104. diem 
application 3 writes an http request, such as: 

GET http://server.eom/HTTP/1 OtCR.LF] 
[CR/LF] 

to connection manager 6. In step 105. connection manager 6 reads this request using 
the read method for http. After successfully reading the request line, the http class 
parses the specified URL to detemiine if it is valid. If the URL is not valid, then 
connection manager 6 signals an error. After successfully parsing the specified URL. 
the http class read method next reads the http header lines. 

After the header lines are read, connection manager 6 cooperates with the 
sen/er to establish a connection using the connect methods (steps 106-108), and 
subsequently invokes the http write methods to write the client request to server 
machine 4 (step 109). Once the server reads this client request (step 110). it writes a 
response (step 111). According to the http protocol, this response consists of a.status 
line, a header, and the body of the response, e.g.: 
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HTTP/1 0 200 OK[CR/LF] 

(CR/LF) 

Hello World! 

5 This response is then read by connection manager 6 (step 112). Like the client 
application, the server's communication through connection manager 6 is transparent, 
and the server cannot discern that connection manager 6 is anything other than an http 
client. 

Once connection manager 6 has received the response from the server, it writes 
10 the response to the client application 3 (step 113). Client application 3 then reads the 
response and displays it to the user (step 114). Thereafter, connection manager 6 
closes the server connection in step 115. and subsequently client application 3 closes 
the connection with connection manager 6 in step 116. The steps associated with all of 
the activities in this http example of FIG. 4A are shown in outline form in FIG. 4B. 
15 The particular methods implementing the http class connection in Example A are 

outlined generally as follows: 

I. http_Classlnit 

A. CreateListener CO 

B. ConnObj_SetlnitMethod(httpJnlt) 
20 C. CreatAdmin? 

1 . CreateListener 

2. ConnObj_SetlnitMethod(http Init) 

II. httpjnit 

A. ConnObj_SetReadMethod(http_Read) 
25 B. ConnObj_SetWriteMethod(http_Write) 

C. [ConnectionManager/Server] 

1. CallMethod(gssJnit) 

III. http_Delnit 

IV. http_Connect 
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V. http_Read 

A. ReadRequestOrReadResponse? 

1. http_Read_Client_Request 

a) http_Read_Clientlnit 
5 b) http_Read_Request 

c) http_Read_ClientHeaderAndBody 
(1) LocalOrRemote? 

(a) http_ProcessLocalURL 

(b) http_ProcessRemoteURL 
'° •) SecureOrUnsecure? 

(1) SetConnectMethod(gss Connect) 

(2) SetConnectMethod(http~Connect) 

ii) OpenRemoteConnection 

iii) Buffer/FlushRequest 
'5 d) http_Read_ClientDone 

2. http_Read_Sefver_Response 

a) http_Read_Sefverlnit 

b) http_Read_Status 

c) http_Read_ServerHeaderAndBody 
20 d) http_Read ServerDone 

VI. http_Write 

A. WriteRequestOrWriteResponse? 

1. http_Write_ClientRequest 

a) WriteComplete? 
-5 ( 1 ) SwitchToRead/WriteResponse 

2. http_Write_Sen/erResponse 

a) WriteComplete? 

(1) ConnObLMarkForDeletion 

VII. http_Exception 

30 

Example B: Secur a Web Connection rass-http) 
Referring to FIG. 5A. there is shown an activity flow diagram for a secure gss- 
http clienVserver connection which is set up and managed by client and server 
components of connection manager 6, namely CM/C 10 and CM/S 12. As in Example 
35 A, client application 3 is presumed to be a Web browser and sender machine 4 Is 
presumed to be a Web server. Prior to the initiation of the activities shown in FIG. 5A. it 
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is presumed that CM/C 10 and CM/S 12 have been initialized and that at least one 
listener object 16 (FIG. 2A) of the http class is active on each of CM/C 10 and CM/S 12. 

The operation of CM/C 10 and CM/S 12 for secure gss-http connections is now 
described. At the outset, the user of client application 3 (Web browser) gives an 
indication in step 201 that he desires secure communications with a server. In 
response, client application 3 attempts to open a connection with CM/C 10 (step 202) 
and CM/C 10 accepts the connection (step 203). The client may then write a request to 
CM/C 10, such as: 

POST http://sen/er.com;488/cgl-bin/foo HTTP/1 0[CR/LF] 
Content-length: 17 

Content-type: application/x-www-form-unencodedfCR/LFl 
[CR/LF] . 

name=John%20Smith 

which includes a request line, header lines, and a user ID. CM/C 10 invokes the read 

IS method to read this request in step 205. 

The http read method observes the content of the request and determines that a 
gss-http secure connection is desired. Thus, the gss connect method will be set as the 
connect method associated with connection object 24 in FIG. 2B. Next, the http read 
method opens a connection to the server (steps 206-208). CM/C 10 then cooperates 

20 with CM/S 12 to establish a connection by invoking the connection object's connect 
method (in this case. gss_Connect). which performs security context negotiation prior to 
the transfer of any secure data (steps 209-216). The server application 5 (Web server) 
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receives no requests and takes no part in the connection set-up until after CM/C 10 and 
CM/S 12 have successfully negotiated the secure connection. 

Upon completion of the security context negotiation between CM/C 10 and CM/S 
12. http write methods including security protocols are invoked by CM/C 10 to send the 
5 client request securely to CM/S 12. Operating in mirror image fashion. CM/S 12 reads 
the client request in step 218. Thereafter, in steps 219 through 225. CM/S 12 interacts 
with server application 5 to open a connection to the sen/er. send the client request to 
the server, and read the seiver response in a manner analogous to the interaction 
between connection manager and sen/er application 5 in steps 106-112 in Example A 
10 above. The sample response written to CM/S 12 in FIG 5A is. 

HTTP/1.0 200 OK (CR/LF] 
[CR/LF] 

Hello John Smith! 

15 Now that the read and write methods invoked by CM/C 10 and CM/S 12 provide for a 
secure connection, the sen/er response may be securely written to and read by CM/C 
10 (steps 226 and 227) before CM/S 12 closes the server connection (step 228). After 
writing the response to the client (step 229) for display to the user (step 230). the 
remainder of the connections are then closed, first by CM/C 10 (step 231). then by 

20 client application 3 (step 232). Thus, it can be seen from the example that the client 
and sen/er components of connection manager 6 established a secure gss-http 
connection between the client and sen/er by interacting with dient and sen/er in a way 
that transparently mimics direct interaction between client and sen/er. 
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The particular methods implementing the gss class connection in Example B 
outlined generally as follows: 

I. gss^Classlnit 
II gssjnrt 
5 A. ConnObLSaveCunrentMethods 

B. ConnObLSetReadMethod(gss_Read) 
Ifl. gss_Delnit 
IV gss_Connect 
A. gss_rnit 
10 IV. gss_Read 

A. [ConnectionManager/Client] 

1. gss_ReadJnit 

a) gss_AcquireAndFlushToken 

2. gss_Read_Token 

J 5 a) gss_Read_TokenHeader 

b) gss_Read_TokenBytes 

c) gss^AcquireAndFlushToken 

d) NegotiationComplete? 

(1 ) SetSocketParametersForTransparentEncrypt/Decrypt 
20 3. gss_Read_FirstEncrypted 

4, gss_Read_Done 

a) ConnObLRestoreCun-entMethods 

B. [ConnectionManager/Server] 

1. gss_ReadJnit 
25 2. gss_Read_Token 

a) gss_Read_TokenHeader 

b) gss_Read_TokenBytes 

c) gss_AcquireAndFlushToken 

d) NegotiationComplete? 

(1) SetSocketParametersForTransparentEncrypt/Decrypt 

(2) ConnObLSetWriteMethod(gss_Write) 

3. gss_Read_Done 

VI. gss^Wrtte 

A. [ConnectionManager/Client) 
35 B. [ConnectionManager/Server] 

1 . BufferAcknowledgement 

2. WriteComplete? 

a) ConnObLRestoreCun-entMethods 

VII. gss_Exception 

40 
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While a particular embodiment of the invention has been illustrated and 
described, it will be obvious to those skilled in the art that various changes and 
modifications may be made without sacrificing the advantages provided by the 
principles of construction and operation disclosed herein. 
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CLAIMS 

We claim: 

1 . A computer system providing enhanced communications between a client 
application and a server application, comprising: 

5 a client machine running said client application; 

a connection manager interoperable with said client application to: 

(a) receive from said client application a connection request for a 
specific type of connection; 

(b) identify the type of connection requested from a 
10 plurality of connection types; and 

(c) invoke methods for the type of connection requested, thereby 
establishing a connection between said client application and said 
server application. 

2. A method of enhancing communications between a client application and a 

15 server application in a client/server computing environment, comprising the steps of: 
receiving from said client application a connection request for a 

specific type of connection, said connection request including a body; 
identifying the type of connection requested from a plurality of connection types; 
invoking methods for the type of connection requested; and 

20 writing said body of the connection request to said server application. 
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